1. Field
Embodiments of the invention relate generally to computer-based simulations and more particularly to techniques for passing non-architected registers via a callback/advance mechanism in a simulator environment.
2. Description of the Related Art
Computer simulators are often used to model other computers, with modern simulators being capable of simulating hardware architecture with a very high degree of precision. These simulators are highly useful for a broad variety of applications, such as software development, performance testing, hardware architecture prototyping, and educational purposes, to name but a few examples.
International Business Machines (IBM) has developed a full-system simulator for modeling Power PC systems under the name Mambo. Simulators such as Mambo may be configured to simulate a specific set of hardware and to execute user programs designed for that hardware. Additionally, simulators may execute these programs while maintaining a high level of detail regarding the operations of the simulated hardware. As such, one common use for simulators is to develop and test software applications for a given hardware architecture before the actual hardware is made readily available to the development community. Simulators allow software developers to begin the development process before they have actually acquired the physical hardware, allowing them to begin development without waiting until the hardware is physically manufactured and available for public use. Additionally, by using a simulator, developers may save on equipment costs by avoiding purchasing expensive hardware they are developing applications for. In situations where the physical hardware is expensive, these savings may be substantial and the use of a simulator essential.
Additionally, hardware architects may use highly accurate simulators to test potential hardware architectures before they are physically manufactured. The use of these simulators may result in substantial cost and time savings for hardware manufacturers. Developing and fabricating a modern computer processor is a difficult and expensive process in terms of both time and resources. Furthermore, if a defect or a performance bottleneck is found in the design after the hardware has been manufactured, this may result in a sizable waste of time and resources. However, by testing the hardware architecture first in a highly accurate simulator, these potential defects and performance bottlenecks may be corrected before the hardware is physically manufactured, thus resulting in significant cost and time savings for the manufacturer.
Modern simulators may be written to maintain various levels of accuracy regarding the hardware being simulated. For instance, simulators may be clock cycle-accurate, where every operation performed by the processor at each clock cycle is simulated. However, this high level of detail comes at the cost of added complexity and decreased performance for the simulation. Thus, in a situation where a user is only concerned with how a particular computer program runs on the simulated hardware (and not about the lower-level operations of the simulated hardware), a cycle-accurate simulator may not be ideal. Alternatively, simulators may be designed to maintain instruction-level accuracy, where the accuracy of the simulator is limited to the instruction level and each and every lower-level hardware operation is not necessarily simulated. However, while instruction-accurate simulators often achieve performance gains over cycle-accurate simulators, this performance comes at the cost of information about the underlying hardware being simulated. Thus, instruction-accurate simulators may not be appropriate for certain tasks, such as testing the performance of a particular hardware architecture.
Because each user using a particular simulator may prefer a different level of accuracy, additional customization in a simulator may be beneficial. For example, a simulator that can be configured to provide instruction-level accuracy for a first user, and reconfigured to provide cycle-level accuracy for a second user, allows users to reduce expenses by sharing a single simulator while retaining the advantages of using a simulator with their preferred accuracy-level and performance. Additionally, in some circumstances, a user may prefer to have cycle accuracy for certain instructions in a user program, and may not care if the simulator is cycle-accurate for other instructions. In such a situation, a hybrid approach, where performance counters are only calculated for particular instructions, may be advantageous.